…4340 后续) (#4417)

* fix(lint,cli): os lint / os compile 不再放行一个 os validate 会拒绝的 react 页面 (#4340 后续)

`validateReactPageProps` 只手工接在 `os validate` 上,`os lint` 和 `os compile`
从来没跑过它。在 showcase 的 react 页面植入一处 gating 违规
(`<ListView filters={['no_such_col','=',stage]}>` —— 谓词命中不了任何行,
SqlDriver 吞掉 "no such column" 后返回 [],列表回空且与「本来就没数据」无法区分)
实测:

              os lint      os compile     os validate
  修复前      exit 0 放行   exit 0 放行    exit 1 拒绝
  修复后      exit 1 拒绝   exit 1 拒绝    exit 1 拒绝

#4340 之后这条规则已经是整个 react 页面表面唯一的字段解析闸门:<ListView> 的
columns/fields/sort/grouping/userFilters、<ObjectForm> 的
fields/initialValues/sections/subforms、record:* 一族(与元数据表面共用同一张
COMPONENT_FIELD_SPECS)、<ObjectChart> 的 aggregate/axes,以及 searchableFields。
所以漏接不是少几条警告 —— 而是这些绑定在 build 路径上完全没人看,包括其中会 gate
的那些。

现接入 REFERENCE_INTEGRITY_RULES,`os validate` 那处手工接线随之删除,三个命令的
答案由构造保证一致。这正是 suite 设立要终结的漂移(#3583 §5 D5),也是
validateReadonlyFlowWrites 在 #4394 里刚走过的同一条路:那次是「一张 map、
两个检查、两套命令集合」,这次是「一次 JSX parse、七个 rule id、一套命令集合」。

按 charter,react-prop-missing-required / react-prop-typo 是 shape 而非解析问题,
本不属于 suite。它们随行的理由与 validateActionBodyWrites 完全相同(其注释已写明):
落在同一次 parse 的同一份 source 上,拆成第二个 member 就要把每个 react 页面
parse 两遍,而改回手工接线正是 suite 要终结的那种漂移。同时更正了那条注释里
"The ONE member here that emits two rule ids" 的说法 —— 现在不止一个。

规则行为零变化:id、严重级、文案都不动;输入也不变(`os validate` 原本就传
result.data,suite 拿到的是同一个)。#4402 的接线守卫会在下次有人想再手工接一条
规则时直接报错——本次删除 validate.ts 的直接 import 也正是被它逼出来的。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012rK2McPogrTJBKdUsThrGs

* docs: validating-metadata 反映 react 页面字段绑定现在三个命令都跑

本 PR 把 react 页面的字段绑定检查从「只在 os validate」变成「suite 成员,三个命令
都跑」,这份文档有三处随之失真 —— 而 docs-drift 的包级扇出恰好没点到它(它按
@objectstack/cli / @objectstack/lint 列了 20 份,漏了语义上唯一真正耦合的这份)。

- "one gate, two entry points" 表补一行 React page block field bindings(两列都 ✓)。
- 表下那句把 "JSX/React page sources" 整体算作 os validate 独有 —— 现在只有
  「源码能否 parse」这个 SHAPE 闸门是独有的,里面的字段绑定属于 reference-integrity,
  suite 跑到哪它就跑到哪(含 os lint)。改写为分开陈述,并记下这里曾经的漂移与
  #4384 的接线守卫。
- 示例 os validate 输出里的 `→ Checking React-source page props (ADR-0081)...`
  随手工接线一并删除,已按真实 CLI 输出核对:示例里的每一行 step 现在都能在
  showcase 上逐字复现(comm 比对为空)。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012rK2McPogrTJBKdUsThrGs

---------

Co-authored-by: Claude <noreply@anthropic.com>

…ands (#4409) (#4445)

* fix(cli): every author-time rule that can gate runs on all three commands (#4409)

`os validate`, `os build` and `os lint` each hand-wired their own subset of the
author-time rules. Nothing connected the three lists, so "which rules run here?"
was answerable only by diffing three 800-line files by eye — and the answer
drifted every time a rule landed. The audit found 23 of 26 rules running on some
strict subset, nine of them able to emit `error`.

The worst direction was the least obvious: `os build` — the command that
PUBLISHES — was the weakest gate of the three. A flow whose expression approver
does not parse (`approval-expression-invalid`) built and published green; only
`os lint` stopped it, and CI usually runs the other two.

This is the same failure mode's fifth appearance (#3583, #3782, #4384/#4394,
#4402). Each earlier repair removed an instance and left the MODE: a rule's
command coverage was whatever its author remembered to type, and forgetting was
silent. #4402's guard could not catch the rest — it filtered on the current
member names of one suite, so a rule hand-wired into two commands from outside
that suite passed it without a word.

Replace remembering with a table:

- `packages/cli/src/lint/authoring-rules.ts` declares all 26 rules as data —
  tier (gating/advisory), which stack tier they read (pre-parse vs parsed),
  which commands run them, and a written reason for the one narrowing. All three
  commands consume it through `runAuthoringRules()`; the three command files
  shrink by ~1000 lines between them.
- `authoring-rule-wiring.test.ts` upgrades the guard from a name list to a
  ratchet: a gating rule on fewer than three commands fails, a narrowed rule with
  no reason fails, a command that calls a rule directly fails, and an `advisory`
  claim is checked against the rule's own source so a gate cannot wear an
  advisory label to buy partial coverage. Remaining direct calls are listed with
  reasons in `DIRECT_CALL_RATCHET` / `LINT_IMPORT_RATCHET`.
- `authoring-rule-command-parity.test.ts` proves the verdict, not just the
  wiring: one case per previously-blind gating rule, plus the issue's own repro
  driven through the real CLI — exit 1 on all three commands where it was
  1/0/0 before.

Two things fall out of one report per run rather than exiting at the first
failing gate: an author with three unrelated problems sees all three, and
`--strict` now covers every advisory instead of the roughly half that happened
to be printed inline.

Also closes the same hole one gate over: `collectAndLintDocs` failed `os build`
and never ran on `os validate`, invisible because the parity guard keyed on the
`lint*`/`validate*` naming convention and that gate is called `collect*`. The
guard now names each shared non-registry gate explicitly.

Cost is not what argued against this: the heavy deps (typescript, sucrase) are
already lazy, and the heaviest rule of the set has run on all three commands as
a suite member since #4340 without anyone noticing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sz61GE1CWCSnGW4qShSEXs

* chore(changeset): author-time rule command-coverage registry (#4409)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sz61GE1CWCSnGW4qShSEXs

* docs: name the ADR-0085 pointers by field, not by the reserved word (#4409)

The role-word ratchet (ADR-0090 D3) counts occurrences per file, and two doc
lines describing `validateSemanticRoles` reintroduced the banned word for a
non-permission concept. Name what the rule actually checks instead:
`stageField` / `highlightFields` pointers.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sz61GE1CWCSnGW4qShSEXs

---------

Co-authored-by: Claude <noreply@anthropic.com>

…om the other side (#4449)

`validateFormLayout` was implemented, unit-tested, exported and given published
rule ids — and no command ever called it. A whole-repo search found the
implementation, the barrel export line and its own unit test, and nothing else:
the rule ran on zero stacks for as long as it existed.

Two changes:

  * register it in `AUTHORING_RULES` as `advisory` on all three commands. It
    walks structured metadata only (no lazy dependency), so `os validate`,
    `os build` and `os lint` pay nothing measurable for it.

  * add the reverse closure to the wiring guard. Every invariant #4409 shipped
    starts FROM a registry and looks at the commands, which cannot see a rule
    that never entered a registry — the same blind spot as #4402's name list,
    one layer up. The guard now subtracts both registries from the `validate*`
    / `lint*` symbols on `@objectstack/lint`'s public barrel; the difference
    must be empty or ledgered with a reason in `UNWIRED_RULE_LEDGER`, which
    ships empty because today's difference was exactly this one rule.

The new tests fail without the registry entry: the closure reports
`validateFormLayout` as unwired, and the liveness test asserts the entry's own
`run` adapter returns both findings for a stack that earns them — membership
alone is not evidence a rule produces output.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gEHJN2NFpS9VMeURvakgD

…objectstack-ai#4462, objectstack-ai#4432, objectstack-ai#4455, objectstack-ai#4449) (objectstack-ai#4520)

* fix(cli,lint): run validateFormLayout, and close the rule registry from the other side (objectstack-ai#4449)

`validateFormLayout` was implemented, unit-tested, exported and given published
rule ids — and no command ever called it. A whole-repo search found the
implementation, the barrel export line and its own unit test, and nothing else:
the rule ran on zero stacks for as long as it existed.

Two changes:

  * register it in `AUTHORING_RULES` as `advisory` on all three commands. It
    walks structured metadata only (no lazy dependency), so `os validate`,
    `os build` and `os lint` pay nothing measurable for it.

  * add the reverse closure to the wiring guard. Every invariant objectstack-ai#4409 shipped
    starts FROM a registry and looks at the commands, which cannot see a rule
    that never entered a registry — the same blind spot as objectstack-ai#4402's name list,
    one layer up. The guard now subtracts both registries from the `validate*`
    / `lint*` symbols on `@objectstack/lint`'s public barrel; the difference
    must be empty or ledgered with a reason in `UNWIRED_RULE_LEDGER`, which
    ships empty because today's difference was exactly this one rule.

The new tests fail without the registry entry: the closure reports
`validateFormLayout` as unwired, and the liveness test asserts the entry's own
`run` adapter returns both findings for a stack that earns them — membership
alone is not evidence a rule produces output.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gEHJN2NFpS9VMeURvakgD

* fix(spec): a stored reference holding an embedded record is not a valid id (objectstack-ai#4455)

`os migrate value-shapes` is the evidence half of the ADR-0104 D1
per-deployment gate, and the scan's own header names the case it exists for: "a
`location` stored as `{latitude, longitude}` or a `lookup` holding an expanded
record object". The second case was never detected. `ReferenceIdValueSchema`
was `z.string().min(1)`, and in a SQL deployment a legacy embedded reference
reaches storage as JSON TEXT — a non-empty string. So a deployment carrying
exactly the values the gate exists to find ran the scan, was told it was clean,
and closed the gate with `--apply`; and because the scan deliberately imports
the write-path predicate, the write path was equally blind, so the value also
survived future writes.

`ReferenceIdValueSchema` now rejects a value whose first non-space character is
`{` or `[`, in the expanded form too — `$expand` produces an object, never its
serialization.

Deliberately narrower than an id charset. `FileReferenceIdValueSchema` can
bound its alphabet because a `sys_file` id is minted by the platform and
nothing else; a reference id is whatever the target object's key holds,
including an external key an ADR-0015 federated datasource supplies. So this
rejects the shape that is provably not an id and leaves the alphabet to the
object that owns it — `CB0-2026-0001`, `SFDC:001xx…` and `ops/eu-west/tenant-7`
stay valid, and the tests pin that.

Regression coverage is at the GATE, not just the schema: the scan test plants
the serialized embedded record, asserts it is counted, and asserts
`valueShapeScanPassed()` is false — the deployment may not record the flag —
then asserts the same value is a write rejection under strict, so the scan and
the validator still answer with one predicate.

Reaches authors through the ADR-0104 warn-first path until a deployment opts
into strict, so nothing starts rejecting writes on upgrade.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gEHJN2NFpS9VMeURvakgD

* fix(metadata-protocol): one canonical type key at the /meta boundary (objectstack-ai#4432)

objectstack-ai#3985 taught the per-type gates to accept both spellings of the `/meta` type
segment. It did not FOLD them, so `/meta/actions/x` and `/meta/action/x`
addressed two namespaces and the layers below disagreed about which one an item
lived in — `SysMetadataRepository` folded to singular on its own, while the
authorization tier above it (`isOverlayAllowed`, `isArtifactBacked`), the
registry heal below it (`restoreArtifactRegistryView`) and the list hydration
all read the caller's spelling.

The damaging half was the hydration. `getMetaItems` registered overlay rows back
into the SchemaRegistry under `request.type`, so one plural-spelled read minted a
PLURAL registry entry; from the next read on `listItems('actions')` was no longer
empty, the singular fallback that had been supplying every code-authored action
stopped running, and one overlay row hid the entire code-authored listing — on a
spelling no DELETE addresses, so it outlived the delete that was meant to lift
it and left listing and dispatch disagreeing about a removed item.

`saveMetaItem`, `getMetaItem`, `getMetaItems`, `getMetaItemLayered`,
`getMetaItemCached` and `deleteMetaItem` now fold the type to its canonical
singular as their first act. Reads of data AT REST keep the other-spelling
fallback: rows written under a plural `type` before this fix are real and
nothing rewrites them on upgrade. What changed is that nothing WRITES or
REGISTERS a non-canonical key any more.

Regression tests fail without the fold: a plural-spelled read mints a phantom
`actions` registry entry and the second read drops the code-authored actions,
and `getMetaItem` echoes back the caller's spelling so a client can round-trip
it into a second namespace.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gEHJN2NFpS9VMeURvakgD

* fix(objectql,service-datasource,runtime): a datasourceMapping rule is routing, not a hint (objectstack-ai#4462)

Measured on `main` during the v17 verification: map an object to a Postgres
datasource with a bad URL and the boot SUCCEEDS, `/ready` answers 200, the
datasource name appears in ZERO log lines, the write returns 201 — and the row
is physically in the DEFAULT store. The operator finds out by opening the
database they declared and finding it empty.

Two causes, one per layer, and each is what makes fixing the other correct:

  * `ObjectQLEngine.getDriver` step 2 read `mapped && drivers.has(mapped)`, so a
    MATCHED mapping rule naming a datasource with no live driver fell silently
    through to the default driver. It now throws — `DatasourceUnavailableError`
    when the connect layer recorded a verdict (objectstack-ai#3828), otherwise an error naming
    the object, the datasource and the two remedies. `default` still resolves
    onward: the default driver keeps its natural name (objectstack-ai#3826), so
    `drivers.has('default')` is false by construction and step 5 IS how routing
    to it works.

  * ADR-0062 D2's phase-1 note deliberately excluded "mapped" from the
    auto-connect gate, to keep `examples/app-crm` byte-for-byte unchanged. That
    note priced only one side. Gate (d) now fires when a mapping rule routes at
    least one object to a datasource, and a `declared-auto` failure is FATAL with
    an operator-readable reason — the same call gate (b) already makes for an
    explicit `object.datasource` binding, correct for (d) now that routing no
    longer supplies a fallback. `OS_ALLOW_DRIVER_CONNECT_FAILURE` still degrades.

The mapped-object list comes from the engine's own matcher
(`ObjectQLEngine.resolveMappedDatasource`, newly public) via
`connectDeclared({ mappedObjects })`. The connection service never re-derives
rule matching: two matchers drifting by one clause would connect a datasource
routing never uses, or route to one nothing connects — the defect again.

`examples/app-crm`'s mapping is DELETED, and that is what keeps the example
unchanged rather than what breaks it. Its `namespace: 'crm'` rule never matched
(`namespace` is deprecated; no object sets it) and its `default: true →
crm_primary` rule routed everything to an unconnected `:memory:` datasource,
i.e. to the default store by fall-through. Honouring it would move the whole
app — platform objects included — onto a database empty on every boot.

Verified against a real boot on a private port, not only in unit tests:
  * unchanged CRM example boots healthy; crm_primary/crm_analytics stay
    `unvalidated` (metadata-only) exactly as before;
  * with a mapping to `postgres://…@127.0.0.1:1/nonexistent_db`, boot exits 1
    with "1 object(s) are routed to it by a datasourceMapping rule (crm_account)
    and have no fallback datasource — their reads/writes would otherwise land in
    a DIFFERENT database than the one they declare ⇒ fail-fast per ADR-0062 D5";
  * under OS_ALLOW_DRIVER_CONNECT_FAILURE=1 the degraded-boot banner carries the
    same sentence and the mapped object's seeds fail instead of silently
    populating the default store.

ADR-0062 D2 carries the amendment; the docs page and the data skill now state
that a mapping rule is routing and fails the boot when it cannot be honoured.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gEHJN2NFpS9VMeURvakgD

---------

Co-authored-by: Claude <noreply@anthropic.com>